Arrangement and method for session control in wireless communication network

ABSTRACT

An arrangement and method for session control in a wireless UMTS radio access network (100) by performing creation and deletion of application-specific packet sessions (PDP contexts) in the network, with application-specific QoS parameters, without requiring the explicit cooperation of the application software (either via software API or modem AT command). This allows session set-up and tear-down control of dedicated packet sessions for particular data services, in a UMTS 3G mobile wireless network, with application-specific QoS parameters, with umodified applications operating over the network.

Field of the Invention

This invention relates to session control in communication networks, andparticularly (though not exclusively) wireless networks such as UMTS 3G(Universal Mobile Telecommunication System 3^(rd) Generation) mobilewireless networks.

Background of the Invention

In the field of this invention it is known that the UMTS specifications:

-   -   [1] 3GPP TS 23.107—3rd Generation Partnership Project; Technical        Specification Group Services and System Aspects; QoS Concept and        Architecture (Release 1999)″    -   [2] 3GPP TS 27.007—3rd Generation Partnership Project; Technical        Specification Group Terminals;    -   AT command set for User Equipment (UE) (Release 1999)″    -   [3] 3GPP TS 23.057—3rd Generation Partnership Project; Technical        Specification Group Terminals; Mobile Station Application        Execution Environment (MExE); Functional description; Stage 2        (Release 1999) and    -   [4 ] 3GPP TS 24.008—'rd Generation Partnership Project;        Technical Specification Group Core Network; Mobile radio        interface layer 3 specification; Core Network Protocols—Stage 3        (Release 1999) work on the principle that data packets for        different data flows relating to specific services, are carried        over separate packet sessions over the air. For example,        streaming audio packets could be carried over one packet        session, web browsing over another, email download over another,        etc. The logic for this is that different QoS parameters        (bandwidth, latency etc.) can be applied to the different        services being used.

The UMTS standards [1] define 4 ‘classes’ of packet flows, based on 4categories of applications:

-   -   Conversational class (e.g., interactive voice/video)    -   Streaming class (e.g., streaming media such as Internet radio,        or streaming video)    -   Interactive class (e.g., web browsing)    -   Background class (e.g., email download).

The corollary of this is that the wireless network needs to know whenparticular services are being used, so that it can correctly route datapackets for each session over the relevant packet session over the air.

The UMTS standards imply a tight coupling between the applications andthe mobile device, whereby the applications inform the mobile device(UE) that they are starting up, and what are the QoS characteristics ofthe traffic they will be sending/receiving. This will either be adirect, software interface in the case of integrated mobile devices asin standards [3] or can be an AT command interface as in standards [2].

However, the problem with the approach in the current set of UMTSspecifications is that they require special versions of applicationsoftware (email clients, web browsers, video streaming clients, etc.) toimplement an (internal or external) interface to the UE. A standard PC(Personal Computer), when connected to a UE, with standard applications,will not support such an interface and therefore cannot support packetflows of different QoS for different applications, as demanded by thestandards.

A need therefore exists for arrangement and method for session controlin wireless communication network wherein the abovementioneddisadvantage(s) may be alleviated.

Stateful inspection is an existing, well-known technology, used inInternet firewalls—a firewall blocks packets coming into or out of anetwork, except those explicitly allowed. Stateful inspection is aprocess whereby the firewall inspects packets flowing into it, impliesthe state of an application-specific packet session via the controlpackets, then allows data packets for that session to flow through thefirewall, if the policy for flows of that type allow it.

The basic example of stateful inspection is the allowing through of TCP(Transmission Control Protocol) sessions originated from inside thefirewall to an IP (Internet Protocol) address on the outside to beallowed, but TCP sessions from outside to be blocked—this is themechanism that allows through web browsing and FTP (File TransferProtocol) requests from the inside of a firewall, but blocks requestsfrom the outside to web servers inside the firewall.

This is done by catching TCP connection request packets (packetsoriginating from inside the firewall with the ‘SYN’ flag set), startingthe TCP ‘3-way handshake’ (as explained, for example, in Chapter 18 of“TCP/IP Illustrated, Volume 1, The Protocols” authored by W. RichardStevens and published by Addison Wesley), then opening up the source anddestination IP addresses and TCP port numbers, forwarding on the packetto the outside and then monitoring the subsequent TCP control packets toensure the connection came up and also to catch the eventual tear-downof the TCP session.

Another example of stateful inspection in firewalls for a UDP-based(User Datagram Protocol-based) service is to allow voice over IP (VOIP)calls through the firewall. In this example, incoming VOIP call-controlmessages are inspected and parsed to reveal the VOIP end-points (IPaddress and port number) and allow voice data packets through thefirewall.

STATEMENT OF INVENTION

In accordance with a first aspect of the present invention there isprovided an arrangement for session control in a wireless communicationnetwork as claimed in claim 1.

In accordance with a second aspect of the present invention there isprovided a method for session control in a wireless communicationnetwork as claimed in claim 19.

BRIEF DESCRIPTION OF THE DRAWINGS

One arrangement and method for session control in a wirelesscommunication network incorporating the present invention will now bedescribed, by way of example only, with reference to the accompanyingdrawings, in which:

FIG. 1 shows a schematic diagram illustrating prior art data flow acrossan Internet network firewall between an inside host and an outside host,and showing set-up and tear-down of a session;

FIG. 2 shows a schematic diagram illustrating prior art VOIP data flowacross an Internet network firewall between a PC and an InternetProtocol telephone set and showing set-up and tear-down;

FIG. 3 shows a schematic diagram of an arrangement illustratingapplication of stateful inspection to UMTS session management, in thecontext of POP3 email download, which is mapped to a ‘background class’PDP context, in accordance with the present invention;

FIG. 4 shows a block schematic diagram illustrating flow of data packetsin a default PDP context of the arrangement of FIG. 3;

FIG. 5 shows a block schematic diagram illustrating detection of emaildownload session control packets to activate a secondary PDP context forthe email download session in the arrangement of FIG. 3;

FIG. 6 shows a block schematic diagram illustrating flow of emailpackets and other data packets, and their respective processing as twoparallel contexts, during the email download session in the arrangementof FIG. 3;

FIG. 7 shows a schematic diagram of an arrangement, similar to FIG. 3,illustrating the use of simultaneous default and secondary PDP contextsto provide separate PDP contexts for the email and data packets of FIG.6;

FIG. 8 shows a block schematic diagram illustrating flow of data packetsin a default PDP context;

FIG. 9 shows a block schematic diagram illustrating detection of VOIPsession control packets to activate a secondary PDP context forcontrolling a VoIP session;

FIG. 10 shows a block schematic diagram illustrating flow of VoIPsession control packets, VoIP packets and other packets, and theirrespective processing as two parallel contexts, during a VOIP session;

FIG. 11 shows a block schematic diagram of a UMTS network, in whichpacket sessions (PDP contexts) are created between UE and SGSN andforwarded on through to the GGSN, where the various packet sessions arebonded back together and connected to the target network (e.g., theInternet) in a single packet stream, in accordance with the invention;

FIG. 12 shows a block schematic diagram illustrating UE packet flowarchitecture in an uplink direction, in accordance with the invention,in the network of FIG. 11; and

FIG. 13 shows a block schematic diagram illustrating UE packet flowarchitecture in a downlink direction in accordance with the invention,in the network of FIG. 11.

DESCRIPTION OF PREFERRED EMBODIMENT(S)

Referring firstly to FIG. 1, a known Internet network firewall 10intermediates between an inside host 20 and an outside host 30.Operation of the firewall 10 is as follows:

-   -   At (1), session set-up begins when an outgoing TCP connection        detected. The firewall 10 is opened up for remote IP address and        source and destination TCP port numbers, and waits for a SYN        response; a session object created by a stateful inspector (not        shown).    -   At (2), the end of 3-way handshake detected, and 2-way TCP        session packets are allowed to flow.    -   At (3), the start of TCP connection tear-down detected with a        FIN packet from the inside host 20.    -   At (4), the TCP session teardown is complete, and far end IP        address & session TCP port numbers are blocked by the firewall        10.

Referring now to FIG. 2, a known Internet network firewall 110intermediates VoIP data flow between a PC (Personal Computer) 120 and anInternet Protocol telephone set 130. Operation of the firewall 110 is asfollows:

-   -   At (1), session set-up begins when an outgoing SIP session        request (INVITE) is detected. The firewall 110 is opened up for        remote IP address and source and destination port numbers for        SIP control messages, and waits for an ACK response; a session        object is created by a stateful inspector (not shown).    -   At (2), a successful ACK is received, and UDP source and        destination port numbers are opened up for an RTP session, based        on fields parsed out of INVITE and ACK messages. 2-way UDP voice        session packets are allowed to flow.    -   At (3), start of SIP connection tear-down is detected.    -   At (4), SIP session teardown is complete, and far end IP address        and session UDP port numbers are blocked by the firewall 110.

However, the firewalls 10 and 110 are known only in fixed-line, i.e.,wired, applications.

The UMTS standards define 4 ‘classes’ of packet flows, based on 4categories of applications (conversational class—e.g., interactivevoice/video; streaming class —e.g., streaming media such as Internetradio, or streaming video; interactive class—e.g., web browsing; andbackground class—e.g., email download).

The wireless network therefore needs to know when particular servicesare being used, so that it can correctly route data packets for eachsession over the relevant packet session over the air.

The UMTS standards imply a tight coupling between the applications andthe mobile device, whereby the applications inform the mobile device(UE) that they are starting up, and what are the QoS characteristics ofthe traffic they will be sending / receiving. This will either be adirect, software interface in the case of integrated mobile devices asin standards, or can be an AT command interface as in standards.

However, the problem with the approach in the current set of UMTSspecifications is that they require special versions of applicationsoftware (email clients, web browsers, video streaming clients, etc.) toimplement an (internal or external) interface to the UE. A standard PC(Personal Computer), when connected to a UE, with standard applications,will not support such an interface and therefore cannot support packetflows of different QoS for different applications, as demanded by thestandards.

In a preferred embodiment, the present invention overcomes this drawbackby applying Stateful Inspection to UMTS Session Management.

Briefly stated, in a preferred embodiment, stateful inspection is usedin a UTRA (UMTS Terrestrial Radio Access) system to examine the datapackets, to detect the existence of different application-specificpacket flows, which then allows packet-sessions, called PDP (Packet DataProtocol) contexts in the UMTS standards, to be created over the airwith the required QoS parameters.

The UE brings up a default PDP context for basic data service; allpackets are then inspected, both incoming and outgoing, andapplication-specific traffic is used to open-up dedicated PDP contextsto carry that traffic. One example of how this is used is detection of aPOP3 email download, mapping it to a ‘background class’ PDP context.

As depicted in FIG. 3, a PC 210 (generally referred to as TE-TerminalEquipment-in UMTS terminology) is coupled, via R interface 215, to UMTSUE 220 (containing a USIM—not shown —which together with the UE forms MT—Mobile Terminal —in UMTS terminology). The UE 220 is coupled throughthe UMTS radio access and core network 230 via at least a default PDPcontext 240. The UMTS radio access and core network 230 is coupled via aGi reference point 250) to the Internet 260, containing an email server270.

Referring now also to FIG. 4, FIG. 5 and FIG. 6, the UE 220 contains astateful inspection session monitor 280.

As shown in FIG. 4, the stateful inspection session monitor 280 monitorspackets 290 on the default PDP context 240, looking for email downloadcontrol messages. In the absence of an email download control message,the UE 220 processes the data packets 290 through RLC (Radio LinkController) 300, MAC (Medium Access Controller) 310 and CDMA(Time-Division Code-Division-Multiple-Access) physical air interface 320in known manner.

As shown in FIG. 5, when the stateful inspection session monitor 280detects an email download control message 330, it causes a sessionmanager 340 to activate a secondary PDP context 350. In the activatedsecondary PDP context 350, the email download control packet(s) areprocessed through RRC (Radio Resource Controller) 360, RLC 370, MAC 380and CDMA physical air interface 390 in known manner.

As shown in FIG. 6, after activation of the secondary PDP context 350,data packets 290 and email packets 400 are processed in parallel inseparate PDP contexts as follows:

-   -   data packets 290 are processed in default PDP context 240, and    -   email packets 400 are processed in PDP context 350.

Thus, as shown in in FIG. 7, the email download session is conductedbetween the email server 270 and an email program 410 (running on the PC210) via the PDP context 350, while the default PDP context 240continues to process data packets as before.

Referring now to FIG. 8, FIG. 9 and FIG. 10, another example applicationof the present invention, is a VoIP session initiation using SIP (as in3GPP RFC—Request For Comments—3261“SIP: Session Initiation Protocol”,June 2002) which is mapped into a conversational class PDP context tocarry the VOIP traffic and an interactive class PDP context to carry theVOIP signalling.

As shown in FIG. 8, the stateful inspection session monitor 280 monitorspackets 290 on the default PDP context 240, looking for VOIP sessioncontrol packet(s). In the absence of a VOIP session control packet, theUE 220 processes the data packets 290 through RLC (Radio LinkController) 300, MAC (Medium Access Controller) 310 and CDMA(Time-Division Code-Division-Multiple-Access) physical air interface 320in known manner.

As shown in FIG. 9, when the stateful inspection session monitor 280detects VOIP session control packet(s) 420, it causes session manager340 to activate a secondary PDP context 350. In the activated secondaryPDP context 350, the VOIP session control packet (s) are processedthrough RRC (Radio Resource Controller) 360, RLC 370, MAC 380 and CDMAprocessor 390 in known manner. Referring now also to FIG. 10, detectionof VOIP session control packet(s) also causes SM 340 to activate afurther secondary PDP context 430.

As shown in FIG. 10, after activation of the secondary PDP context 350and the further secondary PDP context 430, packets are processed inparallel in three PDP contexts as follows:

-   -   data packets 290 are processed in default PDP context 240,    -   VOIP control packets 420 are processed in PDP context 350, and    -   VOIP packets are processed in PDP context 430. Taking the        specific example of the Session Initiation Protocol [RFC        3261—SIP: Session Initiation Protocol, June 2002] the QoS        parameters required for a particular VOIP session can be derived        or inferred from the SIP signalling.

A request to set up a session is contained in an INVITE message, e.g.

-   -   INVITE sip:UserB@there.com SIP/2.0    -   Via: SIP/2.0/UDP here.com:5060    -   From: BigGuy    -   To: LittleGuy    -   Call-ID: 12345601@here.com    -   CSeq: 1 INVITE    -   Contact:    -   Content-Type: application/sdp    -   Content-Length: 147    -   V=0    -   o=UserA 2890844526 2890844526 IN IP4 here.com    -   s=Session SDP    -   c=IN IP4 100.101.102.103    -   t=0 0    -   m=audio 49172 RTP/AVP 4    -   a=rtpmap:4 G723/8000

In this case the ‘c=’ parameter identifies the IP address of the caller,the ‘m=’ parameter identifies this as an RTP audio stream with local UDPport number and the ‘a=’ parameter identifies the characteristics(bandwidth, encoding) of the audio stream.

The response message indicating answer to this might be: SIP/2.0 200 OK

-   -   Via: SIP/2.0/UDP here.com:5060    -   From: BigGuy    -   To: LittleGuy ;tag=8321234356    -   Call-ID: 12345601@here.com    -   CSeq: 1 INVITE    -   Contact:    -   Content-Type: application/sdp    -   Content-Length: 147    -   v=0    -   o=UserB 2890844527 2890844527 IN IP4 there.com    -   s=Session SDP    -   c=IN IP4 110.111.112.113    -   t=0 0    -   m=audio 3456 RTP/AVP 4    -   a=rtpmap:4 G723/8000

In this case the ‘c=’ parameter identifies the IP address of the calledparty, the ‘m=’ parameter identifies this as an RTP audio stream with atype 4 (6.3 kbit/s G.723.1) codec & local UDP port number of the calledparty and the ‘a=’ parameter identifies the characteristics of the audiostream—basically the codec.

Finally the ACK message sent by the caller looks like:

-   -   ACK sip:UserB@there.com SIP/2.0    -   Via: SIP/2.0/UDP here.com:5060    -   From: BigGuy    -   To: LittleGuy ;tag=8321234356    -   Call-ID: 12345601@here.com    -   CSeq: 1 ACK

So, by this time the source and destination IP addresses and portnumbers+the bandwidth required are known—basically enough to set-up asecondary PDP context to send the packets through.

It will be understood that the application of stateful inspection ofpacket flows to control UMTS session management as described in theexamples above presents a new and advantageous technique providing a UEinterface allowing packet flows of different QoS for differentapplications to be supported simultaneously and in parallel, withoutrequiring special versions of application software (email clients, webbrowsers, video streaming clients, etc.).

Referring now to FIG. 11, viewed in the context of the UTRA system ofFIG. 3 or FIG. 7, the VOIP example described above in relation to FIG.8, FIG. 9 and FIG. 10 can be considered as:

-   -   (i) in the UE (220), detecting application-specific session        initiation (incoming or outgoing) and setting up secondary PDP        contexts to carry application packet streams (350 and 430),        and (ii) in GGSN 230C, GTP (GPRS Tunneling Protocol) sessions        from SGSN 230B extending the PDP contexts all the way to the        GGSN. The GGSN can use the per—PDP context QoS parameters (and        any other criteria it sees fit) to classify the IP traffic going        into the target IP network.

Thus, in a UMTS network, packet sessions (PDP contexts) are createdbetween the UE and the SGSN (via the Node B—not shown —and RNC 230A) andforwarded on through to the GGSN, where the various packet sessions arebonded back together and connected to the target network (e.g. theInternet) in a single packet stream.

It will be understood that although the invention has been described inthe above examples with reference to email (POP3) and VOIP sessions, theinvention covers additional or alternative sessions such as:‘conversational’ class (e.g., Video over IP) where traffic may be basedon originated calls controlled by SIP or H.323 protocol; ‘streaming’class (e.g., carrying streaming media traffic controlled by Real TimeStreaming Protocol); ‘interactive ’ class; or ‘background’ class (e.g.,carrying POP3 or SMTP traffic).

It will be understood that stateful inspector and packet filter entitiesexist within the UE; these may be implemented in software, firmware orhardware. The stateful inspector fits in the uplink and downlink packetflow, the packet filter fits in the uplink packet flow (in order tocontrol the split of uplink packets into the correct PDP context). Asession management software entity exists within the UE; it controls theactivation and de-activation of PDP contexts. The relationship betweenstateful inspector, packet filter and session management is illustratedin the FIG. 12 and FIG. 13

Referring now to FIG. 12 and FIG. 13, which show uplink and downlinkpacket flow architectures respectively in the UE (220 or 130A):

The stateful inspector 450:

-   -   Detects application-specific control messages in the uplink and        the downlink.    -   Implements an interface to the session management entity 460 to        control activation/deactivation of application-specific PDP        contexts, including sufficient information regarding the IP        packet flow for that instance of that application        (source/destination IP address, UDP/TCP indicator and        source/destination port number).    -   Implements an interface from session manager 460 to inform it of        timed—out sessions.

Session manager 460:

-   -   Implements the interface from the stateful inspector 450 to        initiate activation/de-activation of secondary PDP contexts.    -   Controls the activation/de-activation of secondary        (application-specific) PDP contexts over the UMTS air interface.    -   Implements an interface to add/delete with uplink packet-flow        filters in the packet filter entity 470 (source/destination IP        address, UDP/TCP indicator and source/destination port number).

The packet filter 470:

-   -   Implements the interface from session manager 460 to add/remove        packet filters and associate them to secondary PDP contexts in        the uplink.

It will be appreciated that the method described above for sessionmanagement in a UMTS radio access network may be carried out in softwarerunning on a processor (not shown), and that the software may beprovided as a computer program element carried on any suitable datacarrier (also not shown) such as a magnetic or optical computer disc.

It will be also be appreciated that the method described above forsession management in a UMTS radio access network may alternatively becarried out in hardware, for example in the form of an integratedcircuit (not shown) such as an FPGA (Field Programmable Gate Array) orASIC (Application Specific Integrated Integrated Circuit).

It will be understood that the arrangement and method for sessioncontrol in a wireless communication network described above provides theadvantage of allowing session set-up and tear-down control of dedicatedpacket sessions for particular data services, in a UMTS 3G mobilewireless network, with application-specific QoS parameters, without theexplicit cooperation of the application software (either via softwareAPI or modem AT command).

1. An arrangement for session control in a wireless communicationnetwork, comprising: means for detecting application-specific packets ina packet stream; and means for activating, in response to the means fordetecting, a plurality of packet sessions with application-specific QoSparameters, without requiring explicit cooperation of applicationsoftware.
 2. The arrangement of claim 1 further comprising means fordeactivating at least one of the plurality of packet sessions.
 3. Thearrangement of claim 1 or 2 wherein the wireless communication networkcomprises a UMTS radio access network.
 4. The arrangement of claim 1, 2or 3 wherein the packet seesions comprise Packet Data Protocol (PDP)contexts.
 5. The arrangement of any one of claims 1-4 wherein the meansfor detecting comprises stateful inspection means, and the arrangementfurther comprises session manager means and packet filter meansresponsive to the stateful inspection means.
 6. The arrangement of anyone of claims 1-5, wherein the means for detecting is arranged toinspect uplink packet flows to detect application-specific packet flows,via application-specific control messages.
 7. The arrangement of any oneof claims 1-6, wherein the means for detecting is arranged to inspectdownlink packet flows to detect application-specific packet flows, viaapplication-specific control messages.
 8. The arrangement of any one ofclaims 1-7, wherein the packet sessions comprise conversational classPDP contexts.
 9. The arrangement of claim 8, wherein the conversationalclass PDP contexts are arranged to carry Voice over IP (VOIP) traffic.10. The arrangement of claim 8, wherein the conversational class PDPcontexts are arranged to carry Video over IP traffic.
 11. Thearrangement of claim 9 or 10 wherein the traffic is based on originatedcalls controlled by Session Initiation Protocol (SIP).
 12. Thearrangement of claim 9 or 10 wherein the traffic is based on originatedcalls controlled by H.323 protocol.
 13. The arrangement of any one ofclaims 1-7, wherein the packet sessions comprise streaming class PDPcontexts.
 14. The arrangement of claim 13, wherein the streaming classPDP contexts are arranged to carry streaming media traffic controlled byReal Time Streaming Protocol.
 15. The arrangement of any one of claims1-7, wherein the packet sessions comprise interactive class PDPcontexts.
 16. The arrangement of any one of claims 1-7, wherein thepacket sessions comprise background class PDP contexts.
 17. Thearrangement of claim 16, wherein the background class PDP contexts arearranged to carry Post Office Protocol-Version 3 (POP3) traffic.
 18. Thearrangement of claim 16, wherein the background class PDP contexts arearranged to carry Simple Mail Transfer Protocol (SMTP) traffic.
 19. Amethod for session control in a wireless communication network,comprising: detecting application-specific packets in a packet stream;and activating, in response to the step of detecting, a plurality ofpacket sessions with application-specific QoS parameters, withoutrequiring explicit cooperation of application software.
 20. The methodof claim 19 further comprising deactivating at least one of theplurality of packet sessions.
 21. The method of claim 19 or 20 whereinthe wireless communication network comprises a UMTS radio accessnetwork.
 22. The method of claim 19, 20 or 21 wherein the packetseesions comprise Packet Data Protocol (PDP) contexts.
 23. The method ofany one of claims 19-22 wherein the step of detecting comprisesdetecting in a stateful inspector, and the method further comprisesproviding a session manager and a packet filter responsive to thestateful inspection means.
 24. The method of any one of claims 19-23,wherein the step of detecting comprises inspecting uplink packet flowsto detect application-specific packet flows, via application-specificcontrol messages.
 25. The method of any one of claims 19-23, wherein thestep of detecting comprises inspecting downlink packet flows to detectapplication-specific packet flows, via application-specific controlmessages.
 26. The method of any one of claims 19-25, wherein the packetsessions comprise conversational class PDP contexts.
 27. The method ofclaim 26, wherein the conversational class PDP contexts carry Voice overIP (VOIP) traffic.
 28. The method of claim 26, wherein theconversational class PDP contexts carry Video over IP traffic.
 29. Themethod of claim 27 or 28 wherein the traffic is based on originatedcalls controlled by Session Initiation Protocol (SIP).
 30. The method ofclaim 27 or 28 wherein the traffic is based on originated callscontrolled by H.323 protocol.
 31. The method of any one of claims 19-25,wherein the packet sessions comprise streaming class PDP contexts. 32.The method of claim 31, wherein the streaming class PDP contexts carrystreaming media traffic controlled by Real Time Streaming Protocol. 33.The method of any one of claims 19-25, wherein the packet sessionscomprise interactive class PDP contexts.
 34. The method of any one ofclaims 19-25, wherein the packet sessions comprise background class PDPcontexts.
 35. The method of claim 34, wherein the background class PDPcontexts carry Post Office Protocol—Version 3 (POP3) traffic.
 36. Themethod of claim 34, wherein the background class PDP contexts carrySimple Mail Transfer Protocol (SMTP) traffic.
 37. The method of any oneof claims 19-36, wherein the method is performed in User equipment (UE).38. User equipment (UE) for use in a UTRA system, the user equipmentcomprising the arrangement of any one of claims 1-18.
 39. An integratedcircuit comprising the arrangement of any one of claims 1-18.
 40. Acomputer program element comprising computer program means for themethod of any one of claims 19-37.